Many software applications are physically or logically split into separate components, or services, which communicate with each other via an inter-process communication (IPC) mechanism. For example, some components/services of a software application may act as server components that provide defined services to other software components. Software components that utilize the services of other software components may be referred to as client components.
In an IPC service, it is useful for one component to be able to send a message to another component without knowing its physical location. That is, the sending component should be able to reach a destination component using an address that is not tied to a specific physical location. In this manner, the sending component does not have to keep track of an address that may change when the destination component is moved. This feature becomes increasingly important in the currently evolving cloud based infrastructures.
It is also useful if a sending component can rely on a constant semantic meaning of a lookup key that can be used to reach a particular type of service. For example, it is useful for a sending component to be aware that “a destination that is reachable with lookup key X always provides service Y”. This way, the lookup key can safely be hard-coded into the sending component without risking that it will ever become obsolete. This type of lookup key is referred to herein as a destination key, or simply a key.
When a constant semantic access key is used, a lookup step must be performed in the IPC system to obtain a physical address corresponding to the destination name. In the lookup process, a destination name is translated to a location-specific address that may be used during the subsequent message transmission.
To do the address lookup or translation, the lookup key, which may be a URL, an integer or set of integers, etc., is provided by the client to a lookup or address resolution service.
The binding, or relationship, between the lookup keys and the server addresses must be maintained somewhere in the system, for example, in one or more tables in a database. The lookup table may be consulted by the client component during lookup, and the client component may cache the returned address values. There may be one single instance of this table, but also several replicated versions of it.
In a direct method, the key value may be hard-coded into the application. A client using a “well-known” number (e.g., a port number that is registered with IRNA) to establish a TCP connection to a server is an example of a hard-coded key.
In other cases, the key value may be resolved indirectly. For example, a client and a server can use a hard-coded common identifier, such as an XML tag, so they can obtain the actual value to use as common key during initial configuration.
The basic objective of both these methods is to avoid key collision, which may occur when two keys (ports) with different semantic meanings end up having the same value in the same communication domain. Such a condition can create havoc when two such applications are co-located in the same communication domain. Both methods fulfill this requirement, but they also suffer from severe limitations.
The direct method is very inflexible, and typically also incurs a high cost for some central administration of the registered keys. It is also susceptible to a limitation of the available value space. For example, the 64,000 limitation of IP port numbers is an example of a limited value space. The 4G limitation on available IPv4 addresses is another example.
The indirect method is more flexible, since it allows locally determined values to be filled in for the common identifiers. However, even this method has limitations, since all values are assigned offline before system startup. This means that a system-wide administration of such values is needed. It also means that it may be harder than necessary to expand a running system with new servers, since all information is coming from an off-line tool.